Introduction

This blog provides information about the guide lines to maintain changes from Development environment till Production environment deliveries.

What will be Covered

• Brief About HaptiX
• Sitecore Introduction
• Best practices to set up Sitecore environments and delivery process at HaptiX

Brief About HaptiX

• At HaptiX, we offer offshore development & outsourcing software and consulting company serving business of anything when it comes to Sitecore / .NET
• We provide complete solutions in web content management and customer experience using Sitecore CMS that fulfill clients needs both today and tomorrow
• IT capabilities and infrastructure are essential for business to survive and thrive. Yet investment is prohibitive and in house resources rarely remain current
• HaptiX not only helping their client to develop a solution but anything when it comes to Sitecore/.NET and also provide a corporate training to the right resource according to the need of their clients and make them work dedicatedly for their client in shorter time
• We are one step solution provider of Sitecore in variations specialties such as Digital marketing, Sitecore foundry, Sitecore, Web Content Management, Customer Engagement Platform, E-Commerce Enterprise and many more.

Sitecore Introduction

• Sitecore, a great Content Management System we work with here at HaptiX. With Sitecore it is possible to place complex content management tasks in the hands of people whose computer skills are limited to the use of text editors.
• From a developer's perspective, Sitecore is a platform which helps with the implementation of internet and intranet systems. Data modeling is done visually through its interface and all customizations are done in .NET, with the use of Sitecore's API to read and write data
• Some of the features Sitecore natively supports
  • Incredibly user-friendly and straightforward admin interface
  • A broad and well organized API which makes it possible to do everything  through the admin interface (and more)
  • Security settings with multiple access permission levels, allowing different users to have different roles
  • Personalized workflows for any page in the system, putting items through a predefined pipeline before they are published.; users with the necessary permissions review the content on each step of the process
  • Multiple languages can be supported with little effort. The system allows for the creation and translation of content items with ease

Best Practices at HaptiX

• We suggest instead of start development straight away, we recommend to think about your environment and delivery process
• We, at HaptiX, recommends to four environment as below. Delivery process is explained in each environment details.
  • Development - This is the first primary and important environment for developers/QA and it focuses on Development and QA Environment. This is the environment where you can catch and fix your errors to make sure about quality of delivery.
  • Build - This is the second environment and amid for integration deployment on other environments. Generally, This environment will be as good as your production environment.
  • Staging/Content Master – This is most important and critical environment. On this environment, page will be designed and content will be populated by various type of users e.g. CE, PE, CA and many more.
  • Production/Content Delivery – This is our LIVE environment where our publish site will be accessible by end users across the glob. Content/pages will be published from Staging to this environment to make live on website. 

Development   

• Refer below terminologies will be used throughout this section:
• Clean Database: - This will be clean database and will be shared for all developers. No one should not play anything with this database and it will be restored from subsequent environments. Only Developer’s packages can be installed on this DB once code is ready for QA delivery.
•  NOTE: While using this database Sitecore Caching issue may come. Usually it won’t   as in Local Development environment developers regularly does        Rebuild/Build     of  a   solution which causes worker process to recycle and it clears the cache. In worst   case if you face any caching issue do IISRESET/Recycle worker process.
• Dirty Database: - This database will be always being dirty and it will be installed on each Developer’s local machine. This database’s sole purpose is for R&D. Do R&D on it as much as you can! Here developer is free to do any DB related changes!

• This will be the “clean database” for development. Here we will restore latest DB backup from subsequent environments (Build/Staging/Prod). After that whenever any developer works on any new functionality/BUG fix and does any change in Sitecore Database on his/her local machine, he/she should create package of it and install that package on this Database. And once done user should change his/her connection string and point it to this DB and Unit test the functionality with this DB again. We will be discussing the benefits of this approach in a while.
• Note that It is responsibility of every developer to install package on this DB. This will make everyone’s including his/her’s life easy! Most important thing is that before installing any packages on this DB please make sure your package is packaged in a right way! (Have any confusion? Better to ask your peer to review your package).
• Hardware & software requirements: This machine should have good disk space and should have installed SQL SERVER 2008.
• Developer’s WorkStation: - Here developers will be working. They do have “dirty” database’s local copy here they can do all R&D, Main development and Bug Fix. Once the task is completed Developer should change his/her connection string and point to “clean” database and do the final unit testing before sending to QA. It’s always best practice to update your solution from SVN after each deployment.
• Hardware & software requirements: Developer’s machine with Visual Studio, SVN, Sitecore, IIS and SQL SERVER needs to be installed.
• QA’s WorkStation: - QA will have their local DB copy with local Sitecore and application connected via SVN. Here they will be deploying package and code sent by Developer. Developer should not access this Database for anything like Add/Modify/Update anything. QA will get package (if exist) and code files from developer. They will install package on local machine and then proceed for their QA process. Also, QA’s local copy should be up to date with SVN repository. It’s always best practice to update your solution from SVN after each deployment. QA should ensure that developer has Unit tested the functionality properly and installed package on "clean” database before starting their testing.
• Hardware & software requirements: QA’s machine with Visual Studio, SVN, Sitecore, IIS and SQL SERVER needs to be installed.
• SVN Server: - Once QA gives green signal to developer that he/she is happy with the changes. Then developer should check in the code in

• As a best practice, update your solution/file before you commit any code, and also do compare and ensure that your code changes are not being conflicted with your peers! If so please do proper merging before commit. Also, please write proper comment before your commit! It will make everyone’s lives easy!
• Hardware & software requirements: SVN Server might be on LINUX/Windows.
• CI Server: - Continuous Integration plays a vital role in Agile Development. It will do automatic build on preconfigured time. Once Build done you can copy the required DLL, Files (aspx, xml etc.) and deployment packages and create Deployment package for Build Server. It will act as a Continuous Integration system. If Build gets failed/successful it should send mail to everyone and notify that build was failed/successful!
• Hardware & software requirements: Machine with Visual Studio, SVN, IIS and SQL SERVER [Optional],Nunit [Optional] If you have some unit tests running on commit, Continuous Integration software (CruiseControl.NET/NANT – Personally I recommend CruiseControl.NET!). Integrate CI Server with IRC channel and Email System.
• This is how it works step by step:
  • Whenever developer gets new task. He/She will be doing the necessary code/database changes in local environment where he /she have local DB copy. If developer does any database change then he/she should create package of it and then move to step2.
    • Below are some benefits of following this step:
    • As every developer will have his/here “dirty” copy they can do R&D on it without taking anyone’s permission and affecting others work.
  • Once developer is done with Step1, he/she should change local copies connection string and point it to “clean” database, install it on “clean” DB and do proper Unit Testing before going to step3. Please note if developer has not changed anything in DB then also he/she should point to “clean” DB and do proper unit testing.
    Below are some benefits of following this step:
    • As every Developer must need to install package on “clean” DB, we will have all DB changes (e.g. Template/Field change) at one centralized DB.
    • It will be good for doing partial Integration Testing (Only DB Changes) for every developer.
    • Regression testing will also be covered while doing Unit testing.
    •  If anyone would like to check anyone’s functionality after deployment, then he/she should take Latest from SVN and point his/her local copy to “clean” DB. No Package search and hassle of configuring the scenario!
  • Once developer is done with Step2, he/she should send updates (Code/Package) to QA. Here QAs will be configuring the updates locally and doing QA.
    • Below are some benefits of following this step:
      • As developer has tested everything in Stpe2. There will be less chance to have errors at this stage. (We did Regression and Integration in step2!).
      • It will be good for doing full Integration Testing (DB + Code Changes) for every QA. If QA raises any BUG then Developer should follow Step1 to Step2 before moving  to Step3.
  • Once QA gives green signal to developer then he/she should check in the code in SVN. You should commit all your packages as well in repository. So, whenever someone would like to install any DB change in his/her “dirty” DB he/she should be able to do it after taking package’s update from SVN.
  • Once CI Server sends Build Successful notification. QA guys should proceed further with creating Deployment package for Build Server.

Build Environment

• This environment will act as a deployment gateway environment. We have already covered need of this environment in introduction section

Staging/CM Environment

• This environment will act as a content management environment. We have already covered need of this environment in introduction section.

Production/CD Environment

• This environment will act as a content delivery environment. We have already covered need of this environment in introduction section.

At a Glance